OK BUTTONS AND VEE PROGRAM FLOW.

I think that OK buttons and similar program flow ideas are a little
difficult to grasp sometimes hence this mini-tutorial.  This is really
aimed at beginners to VEE - more seasoned programmers will find this
rather basic.  Comments, ideas for improvements etc are very welcome -
please use the Questions/Answers/Comments form on the website -
www.PreciselySo.Co.UK

DISCLAIMER, WARRANTY AND COPYRIGHT
These examples are provided on an 'as is' basis with no explicit or
implied warranty.  Copyright is retained by the author but free use
including copying and use for business purposes is expressly permitted.

This explanation goes with a set of VEE files that you should also have
- they are in VEE 5 for widest appeal.

You will have probably already used the OK button under
Flow -> Confirm (OK) but what normally baffles programmers is how to
keep 'charging' the button so that they can have multiple choices.
OK 1.vee example file shows the general idea.  Incidentally, you can
generally use either the 'output' or the sequence out pin from the OK
button unless you want it to double as a "Do" object...

The way to get over this is to have an Until Break, right? OK 2.vee.
Not quite - all 'threads' needs to be satisfied before the Until Break
can start the next iteration.  So then we end up with an Until Break for
each button choice ( not strictly needed for the 'Stop' button ) as in
OK 3.

I have seen the use of a 'toggle' button used as an OK button but I can
see no advantage in this, and sometimes it misses your click - see
OK 4.vee

Having said that, there is one situation I have seen this used to very
good effect - in the examples shipped with VEE.  Have a look at almost
any example e.g. examples\Applications\chaos.vee.  If you press the
'Run' button, the program runs as intended.  Press the 'Info About'
button and the info screen is shown.

Look at the UserObject 'Press for' and you will see the button is a
toggle, reset from the sequence-out pin of the 'Information About This
Example' UserObject and set to Auto Execute.  I just copy the whole
USerObject into my code and change the text in the NotePad which is
shown.

Sequencing OK Buttons
=====================
Here are some other situations where you want to restrict the use of
some buttons until others have been pressed.

OK 5 shows a situation where one thing has to happen before another is
allowed ( e.g. loading a file before running a test ).  However, it is
more likely that other files can be loaded later ( after running the
test ).  We know that an Until Break feeding the 1st OK will not work -
the thread never ends because of the second Until Break.  Further, it is
likely that if the user cancels from the the first 'load file' then the
second will not be valid.

OK 6 shows a solution.  It involves a bit more work, setting up a global
variable in the Initialise UserFunction but it allows much better control
of the process.  For example, if operation 1 does not work properly, the
flag is not set inhibiting operation 2.  Or, during operation 2, a
condition may occur that requires operation 1 to happen before operation
2 can happen again for example a calibration time period may have
elapsed.

Generally I avoid using global variables unless I really need them, but
for any reasonable sized application a set of flags - I use an array
imaginatively called 'Flags' - is a real boon for controlling the user
interface aspects - users can often expect to vary the order in which
they do things and the flags keep a track of what has been set up.

Branching on user input
=======================
You may want different parts of the program to run depending on which
button is pressed, like a 'switchboard'.  There are several ways this
can be done.  For example, each part of your code could be in
UserFunctions - call the corresponding UserFunction depending on which
button is pressed, as per the OK 3.vee example described earlier.

Another way is to have several OK buttons feeding an if/then/else ( plus
extra else-ifs ) to decide which path to take based on the button
pressed.  A slightly smoother example of this is shown in
Menu choice.vee.  Note that, because not all of the threads in the
UserObject are complete when any one button is pushed, there needs to be
an explicit 'Exit UserObject' to close the dialog box.

If you wanted to have cascaded menus then each of the Message Box
dialogs that are shown in the example could be replaced with more
UserObjects like 'Choose flow'.  It is good programming style to have a
'Cancel' or 'Go back' option at each menu choice.


Michael J. Watts Consultant 2001, Apr 2002
